Why add a bunch of new directives for this? It would surely be better to modify the existing directives and make them work for URIs - we could recognise either known URI schemes as we do already for SSLCertificateFile or have something more general.

Why add a bunch of new directives for this? It would surely be better to modify the existing directives and make them work for URIs - we could recognise either known URI schemes as we do already for SSLCertificateFile or have something more general.

The existing directives end in "File" or "Path" respectively, showing they are files and paths. Sneaking a URI into SSLCertificateKeyFile was always wrong, and now that we've done it it forces a lot of backwards compatibility constraints we do not want.

The kicker however is Windows, which stops us putting a URI into any directive containing File, because "c:[stuff]" is a valid URI, and also a valid File, and also a valid Path.

The URI directives are a completely clean break from the past. They can be used alongside the old directives, but old and new don't affect each other's behaviour.

In the bad old days of files and paths an admin was forced to do the manual work of isolating the certs, isolating the intermediates, isolating the keys, then putting them in files in different orders depending on whether the cert was at the front end or in the proxy. The title of "it's hard" was well earned.

In the new world an admin can still do that - or - crucially, they can point the URI at the whole Windows certificate store, and automagically the correct certificate is chosen for them, the correct intermediate cert chain is built for them, and the correct key is aligned with the correct cert.

Or on Linux they can just point at pkcs11: and have the same effect.